First version of Audivolv that evolves Java code that plays audio.
It considers which flo (floating point) vars in Java code are Lvalue and/or Rvalue
when it renames vars to combine different substrings of Java code.

The background color (of the window that changes with the mouse movements and sound)
also evolves the same way. It demonstrates a problem with the evolution:
The color tends to get stuck in certain patterns and not evolve out of them.

There are some bugs in the Java code parsing which make some vars incorrectly appear to be Lvalue/Rvalue,
but 100% precision is not needed at this early stage of evolution algorithms.
For advanced evolution algorithms, in then next few Audivolv versions, it will be needed. 

Graphics automatically adjust (sometimes way too much) to try to stop sound from skipping,
so if you want better graphics, choose a better sound-card or decrease sound quality.
Sometimes graphics adjust too much and become slow. 

Added temporary buttons to control evolution of Java codes that play audio.
(They are temporary because Audivolv should instead interpret mouse movements to
know if the Human user likes the currently playing sound/mouse/color/etc or not,
which can be done by scoring code higher if it predicts the user's mouse movements better.)

Started building the hypercube function system, a subset of the audivolv.Func interface.
In math, a hypercube is an N-dimensional cartesian space where each dimension has the same range.
In Audivolv, each dimension ranges -1 to 1, and any var exceeding that must go back
in that range before the Func finishes execution.
Because parts of some Java codes can exceed that range,
arbitrary replacement of vars with other code is not allowed in this 1 system.
Instead, there are some default hypercube Java codes it starts with and all
Java code that evolves from this system is a combination of those,
allowing Java vars to be renamed to overlap vars of the other codes in any combination. 